Conversation
62cfdde to
98490b4
Compare
labbott
approved these changes
Aug 12, 2025
Contributor
labbott
left a comment
There was a problem hiding this comment.
LGTM, thanks for doing this
4f42dfa to
a00701b
Compare
98490b4 to
3f9d1d2
Compare
a00701b to
b6ee1b8
Compare
3f9d1d2 to
6a17ab8
Compare
6a17ab8 to
c8eba88
Compare
c8eba88 to
387b862
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(staged on top of #556)
This PR switches stack printing to use
addr2line. Stack unwinding remains the same, using our own code, but now we pass each PC in the stack toaddr2lineto get a more precise backtrace.Before
After
There are three noticeable improvements:
main,get_token,ping, andsys_sendare all at the same stack frame!)This changes a zillion files in the test suite, because we now use
addr2linedata instead of unwind frames when possible.One noticeable change is that we now show the same PC address (starting with
0x080...in the example above) for all frames in an inlined stack. Previously, we used theaddrof each symbol, which is a slightly different behavior; I think it represents the start of the inlined function.I did a spot check, and the new results seem reasonable.
Here's an example diff:
SP = 0x20002b70 <- i2c_driver: 0x20002800+0x370 | +---> 0x20002b80 0x08015ac8 userlib::sys_irq_control_stub - 0x20002c00 0x080148e2 drv_stm32h7_i2c::I2cController::write_read - 0x20002c00 0x08014658 drv_stm32h7_i2c_server::main::{{closure}} - 0x20002c00 0x08014658 userlib::hl::recv_without_notification::{{closure}} - 0x20002c00 0x080142d4 userlib::hl::recv - 0x20002c00 0x080142d4 userlib::hl::recv_without_notification + 0x20002c00 0x08014920 drv_stm32h7_i2c::I2cController::write_read + 0x20002c00 0x08014920 drv_stm32h7_i2c_server::main::{{closure}} + 0x20002c00 0x08014920 userlib::hl::recv_without_notification::{{closure}} + 0x20002c00 0x08014920 userlib::hl::recv + 0x20002c00 0x08014920 userlib::hl::recv_without_notification 0x20002c00 0x08014920 main 0x20002c00 0x0801404e _startI extracted the I2C driver code, then disassembled it to see what these actually addresses represent.
The new dissassembly puts everything at 0x8014920, which is
That certainly is a function call! (to be pedantic, it's the return address after the function call)
The old trace includes the following addresses:
None of these are function calls or values of the PC on the stack. They may be the beginning of inlined functions, but it's awfully hard to tell what's going on, so I think it's fine to discard this information.